In certain applications of communications systems, for example, communications testing products, it is necessary to generate simulated network traffic. As part of this simulation, users will need to construct and modify data packets, often called Protocol Data Units (PDUs) which are then transmitted as the simulated traffic. The format and content of each PDU is based on previously-defined communications protocols. A protocol defines the format, length and meaning of the fields or data elements which a PDU contains. Some protocols define optional fields, which may or may not be included in a PDU. Also, in order to build a complete PDU, users will generally need to encapsulate several different protocols in layers, in both standard and non-standard sequences. Each protocol may be industry standard or proprietary to a particular network equipment vendor.
A software tool used to construct and edit PDUs is called a PDU Builder, and is typically accessed by a user through a Graphical User Interface (GUI). One such tool is used in a communications testing product called “Router Tester” and is available from Agilent Technologies, Inc. of Palo Alto, Calif., USA, which tool is hereby incorporated by reference herein.
The GUIs for current PDU Builders have a similar look and feel. Typically, the protocol fields in a PDU are displayed in a window using standard GUI controls, such as Edit Boxes, Check Boxes, etc. In most cases, each protocol is displayed in a separate window, and to edit a multi-layer PDU the user must switch back and forth between several windows. In some cases, more than one protocol is displayed in a single window, but only a small number—usually no more than two. And in these cases, not all the fields in the protocols can be displayed in the window, because of the limitations of screen space.
There are several disadvantages of this approach. One such disadvantage is that users must switch between several different windows to construct and edit a multi-layer PDU, because each protocol layer of the PDU is displayed in its associated window. Thus, it is not possible to see the entire PDU at once. A further problem with existing systems is that the number of protocol layers that can be supported is small, in the order of about 3-4 layers. The design of such systems has intrinsically limited scalability, because adding more protocol layers means adding more and more windows, thereby making the GUI increasingly more complex and less usable.
Further problems with existing systems are that protocol layering can only be done in one of a few fixed and well-known sequences, and that the size of protocols and PDUs that can be displayed is limited by the size of the windows. Also the choice of protocols is limited to a relatively small list of well-known standard protocols. In addition, optional fields are only supported in a very limited and indirect way.